Some authentication systems use geolocation data to make a determination if a particular user is a fraud. For example, consider a client X of a Local Bank who logs into his account using his smart phone at 7:00 AM to transfer funds to another account. As part of his login sequence, a client application on the smart phone requests geolocation data from the smart-phone; the smart phone then provides geolocation data to an application server at the Local Bank. The server would perform a search of a database and find that client X is in New York City within 3 meters of the location at which he logged in to his account using the smart phone 24 hours ago. The server would then determine that the risk of fraud is low as the user is in the location at which he normally performs such a function and at a time he normally performs such a function.
Suppose that, thirty-five minutes later an unknown user attempts to log into client X's account at Local Bank. Suppose further that the smart phone provides geolocation data indicating it is in Los Angeles rather than New York City. The server would then determine that client X could not travel from New York City to Los Angeles in thirty-five minutes. The server would also determine that the risk of fraud is high because the speed at which the client would have traveled is beyond a limit set by Local Bank. When the server determines that the risk of fraud is elevated, additional authentication steps are performed.
A conventional authentication system used by Local Bank stores the geolocation data for later use in the database in order to calculate the speed of the user on his next attempt to log into the banking application.